8.05. Асинхронная коммуникация
Асинхронная коммуникация
Асинхронность в интеграциях
Мы уже изучали асинхронность, поэтому можем уже понять, что асинхронная коммуникация — это способ взаимодействия, при котором отправитель не ждёт немедленного ответа от получателя. Это особенно важно в распределённых системах, где синхронные вызовы могут привести к задержкам или блокировкам. При таком решении используется либо очередь, либо события. Мы их ранее рассматривали вкратце.
Асинхронная коммуникация обеспечивает передачу сообщений между компонентами системы без необходимости немедленного ответа. Транспортные протоколы и платформы определяют правила доставки, хранения, маршрутизации и обработки сообщений.
Примерами асинхронного взаимодействия может являться:
- SMTP, отправка электронной почты. Клиент отправляет письмо, но не ждёт подтверждения его доставки получателю.
- JMS (Java Message Service), использование очередей сообщений для передачи данных между системами.
- RabbitMQ/Kafka, брокеры сообщений, которые позволяют асинхронно обмениваться данными.
Очереди сообщений
Очереди сообщений (Message Queues или MQ) подразумевает, что сообщения помещаются в очередь, и сервисы обрабатывают их по мере готовности.
Примеры решений - RabbitMQ, Apache Kafka, Amazon SQS. Используется для задач, которые могут выполняться в фоновом режиме (например, отправка email).
Транспорт в асинхронной коммуникации:
- SMTP;
- AMQP;
- MQTT;
- Kafka.
SMTP
SMTP (Simple Mail Transfer Protocol) — это протокол для отправки электронной почты. Он используется для передачи сообщений между почтовыми серверами или от клиента к серверу. Письмо отправляется, но доставка может занять время. Для повторной отправки в случае сбоя используются очереди.
Архитектурные особенности
- Работает поверх TCP (порт 25, 465 для SSL, 587 для submission).
- Использует текстовый формат команд (HELO, MAIL FROM, RCPT TO, DATA).
- Не хранит сообщения: передаёт их от одного агента передачи сообщений (MTA) к другому до достижения конечного почтового ящика.
- Поддерживает расширения через ESMTP (расширение размера сообщения, аутентификация, шифрование).
Механизмы надёжности
- Повторная отправка при временных сбоях с экспоненциальной задержкой.
- Уведомления о недоставке (DSN — Delivery Status Notification).
- Отсутствие встроенной гарантии доставки «ровно один раз» — возможна дубликация или потеря.
Типичные сценарии применения
- Массовая рассылка уведомлений.
- Интеграция с почтовыми сервисами для отправки отчётов.
- Системы, где допустима задержка доставки в минуты или часы.
Ограничения
- Не предназначен для обмена структурированными данными в реальном времени.
- Отсутствие поддержки очередей, маршрутизации по контенту, подтверждения обработки.
MQTT
MQTT (Message Queuing Telemetry Transport) — это лёгкий протокол для передачи данных в условиях ограниченной пропускной способности или нестабильного соединения. Он часто используется в IoT (Интернет вещей). Устройства могут подписываться на темы и получать обновления.
Архитектурные особенности
- Работает поверх TCP/IP (стандартный порт 1883, 8883 для TLS).
- Центральный элемент — брокер, управляющий темами (topics) и подписками.
- Иерархическая структура тем с поддержкой wildcard-подписок (+, #).
- Минимальный оверхед заголовка (2 байта для большинства сообщений).
Уровни качества обслуживания (QoS)
- QoS 0: «не более одного раза» — без подтверждения.
- QoS 1: «как минимум один раз» — подтверждение доставки, возможна дубликация.
- QoS 2: «ровно один раз» — двухэтапное подтверждение, исключает дубли.
Механизмы надёжности
- Keep-alive и автоматическое восстановление сессии.
- Retained messages — последнее сообщение по теме сохраняется для новых подписчиков.
- Last Will and Testament — сообщение, публикуемое брокером при неожиданном отключении клиента.
Типичные сценарии применения
- Интернет вещей (IoT): датчики, встраиваемые устройства.
- Мобильные приложения с нестабильным соединением.
- Системы телеметрии и мониторинга в реальном времени.
AMQP
AMQP (Advanced Message Queuing Protocol) — это протокол для асинхронного обмена сообщениями между системами через брокеры сообщений (например, RabbitMQ). Сообщения хранятся в очередях до тех пор, пока не будут обработаны.
Архитектурные особенности
- Модель «публикация-подписка» с промежуточным звеном — брокером сообщений.
- Ключевые элементы:
- Exchange — точка входа для сообщений, определяет правила маршрутизации.
- Queue — буфер хранения сообщений до обработки потребителем.
- Binding — правило связи между exchange и queue (например, по routing key).
- Поддержка нескольких типов exchange: direct, topic, fanout, headers.
Механизмы надёжности
- Подтверждение получения (acknowledgement) на уровне потребителя.
- Персистентность сообщений и очередей.
- Транзакционная передача (опционально).
- Гарантии доставки: «хотя бы один раз», «ровно один раз» (при настройке).
Типичные сценарии применения
- Декуплинг микросервисов.
- Обработка фоновых задач (очереди задач).
- Системы с требованием гарантированной доставки и упорядоченности.
Реализации
- RabbitMQ — наиболее распространённая реализация.
- Apache Qpid, ActiveMQ (поддержка AMQP 1.0).
Apache Kafka
Kafka — распределённая платформа потоковой обработки, сочетающая свойства очереди сообщений и журнала событий.
Архитектурные особенности
- Модель хранения: неизменяемый упорядоченный журнал (log), разделённый на партиции (partitions).
- Каждое сообщение имеет смещение (offset) внутри партиции.
- Партиции реплицируются между брокерами для отказоустойчивости.
- Потребители организованы в группы (consumer groups): каждая партиция обрабатывается одним потребителем в группе.
Механизмы надёжности
- Персистентное хранение на диске с сегментацией и индексацией.
- Репликация с настраиваемым фактором (replication factor).
- Подтверждение записи (acks): 0, 1, all — контроль над потерей данных.
- Гарантия упорядоченности в пределах партиции.
Типичные сценарии применения
- Построение data pipelines между системами.
- Сбор и агрегация логов и метрик.
- Событийно-ориентированная архитектура (event sourcing).
- Потоковая аналитика в реальном времени.
Отличия от классических очередей
- Сообщения не удаляются после чтения — хранятся до истечения TTL или достижения размера.
- Параллелизм достигается за счёт партиционирования, а не за счёт конкурентного доступа к одной очереди.
- Поддержка потоковой обработки через Kafka Streams и интеграцию с ksqlDB.